The European Commission (EC) aims at a common Pan-European emergency call system, named “eCall”. eCall is based on the existing emergency call system (112 and E112) complemented with some new features. One of these features is that the eCall can be generated automatically at a car crash (e.g. triggered by airbag sensors) or manually by passengers pressing an emergency button. Another feature is that the in-vehicle emergency system (IVS) establishes an emergency voice call to the short number 112 providing additional routing information through the so-called “service category” information element (SC-IE). This SC-IE is a three-octet parameter (see 3GPP TS24.008) and contains two eCall-specific flags (bit 6 and bit 7 of 1 . . . 8; 8=MSB) that allow differentiated routing by the mobile network according to:
bit 7-bit 6:
00b: normal emergency call
01b: manually triggered eCall
10b: automatically triggered eCall
11b: undefined
According to another feature the IVS sends additional data to the public safety answering point (PSAP), also called public emergency point hereinafter, containing information about the accident, such as position, time stamp, car type, etc. These data are currently termed “minimum set of data” (MSD) with minimum indicating that additional data may follow in future specifications.
Furthermore, the current 3GPP standards define a specific inband modem for eCall to transmit this MSD from the in-vehicle emergency system to the public emergency point. This inband modem is designed to transfer exactly 140 octets from the in-vehicle emergency system to the public emergency point, but only a few commands from the public emergency point to the in-vehicle emergency system. No data can be sent from the public emergency point to the vehicle emergency system.
This inband modem has been criticized as being too inflexible, not future proof and as to costly for deployment due to the risk that the existing mobile and wireline networks may need to be modified to allow these inband modem to operate all over Europe.
The applicant has therefore developed an alternative method to transmit the MSD and all future eCall data from the in-vehicle emergency system to the public emergency point by means of a modified SMS protocol, termed “eSMS”. FIG. 5 shows a block diagram of the known eSMS solution. The in-vehicle emergency system (IVS) 1 is shown on the left side. It contains the necessary logic and sensors for the eCall triggering and determining of the position (e.g. via GPS). It also contains a GSM radio modem chipset supporting at least voice calls and SMS. The chipset is slightly modified to include the service category IE as required by the European Commission and it contains in addition, specifically for eSMS, small modifications for a fast transmission of the SMS during the time when the voice call exists.
The Serving MSC 2 in the middle contains the mentioned routing tables for the Emergency Voice call (not shown). In addition the MSC 2 is slightly modified to evaluate the Service Category IE for routing (as required by EC).
Further the MSC 2 is modified allowing a fast transfer of the SMS in GSM and for filtering the eSMSs out of the millions of normal SMS (see more below).
The PSAP 3 on the right side contains the usual equipment for handling the emergency voice call (not shown).
In addition the PSAP 3 has an IP-Interface, which is usually necessary for many good reasons, i.e. Inter-PSAP-communication, communication between PSAP and the various rescue teams (police, fire brigade, ambulance, helicopter service and more). It is assumed that an eCall-equipped PSAP will anyway have an IP-interface.
For eSMS an “Virtual Private Network Tunnel” (VPN-Tunnel) is established on a permanent basis. The MSC and PSAP exchange eCall related data through this VPN tunnel.
The IVS 1 uses standard, available AT-Commands (e.g. according to ITU-T standard V.250) to trigger the emergency voice call and to send and receive the SMS to and from the GSM chip set within the vehicle.
The existing signaling channels of the mobile network (dashed lines) are used for eCall Data transfer.
eSMS is a normal SMS with SMS-Service-Center=112;
eSMS is running fast over the existing GSM signaling channel (<1.5 sec from IVS 1 to PSAP 3) by using the existing FACCH (Fast Associated Control Channel). The FACCH uses “frame stealing”, i.e. it replaces when needed a speech frame by a FACCH frame. This is performed comparably rare and is therefore not audible. By this frame stealing the eSMS gets automatically the same high priority in the radio network as the emergency voice call.
The MSC filters the eSMS (remember: SMS-SC=112) out of the masses of normal SMS and sends the eCall Data directly and fast via secured IP to the PSAP.
Like the MSC routes the voice path to the next local PSAP, it also routes the eCall-Data to the same local PSAP or a central eCall-Data-Server. The choice of architecture is left to the PSAP-organization(s).
The correlation between Voice Call and eCall-Data is based in the phone number of the IVS. It may be noted here that the Serving MSC adds the IVS-number in both cases: to the Voice call (as originating number sent to the PSAP) and in the SMS (as originating number send to the PSAP in the SIP Messages). So the IVS-Number can not different between voice and SMS (SIP).
Besides this public Pan-European eCall Initiative, driven by the EC, so-called Third Party eCall Services or private emergency points exist for several years. These private emergency points can be considered as a private version of emergency services. They are in general advanced with respect to the details of crash data that are sent from the in-vehicle emergency system to the private emergency point. The majority of these private eCall systems uses standard SMS for data transmission.
These private emergency points are profit-oriented and not free of charge, but they have a high potential to drive research and find solutions for better crash analysis and more precise crash data, and it is expected that they will always provide advanced services compared to the free-of-charge public eCall service.
The current public eCall standard has the drawback that the defined inband modem cannot send any data from the public emergency point to the in-vehicle emergency system. Even if the standard was enhanced to allow data exchange in both directions, the nature of inband transmission would always be limiting, because it interrupts the voice communications for a substantial amount of time and its usage must therefore be constrained to a minimum.
The most important benefit of the public eCall standard is that is has support by the mobile networks to find the next local public emergency point based on the actual position of the in-vehicle system when setting up the emergency voice call. The mobile networks, more specifically the mobile switching centers (MSCs) of these networks, are able to identify the radio cell where an emergency voice call is initiated and have hand administered routing tables which contain the telephone numbers of the next local public emergency point. These tables are always up-to-date, as the public authorities take care to update these tables in close corporation with the mobile network operators. The MSC addressed public emergency point may divert the incoming eCall based on the service category or other information, or it may forward the eCall to another PSAP for various internal reasons, for example due to local overload. It is therefore not obvious for the in-vehicle emergency system which public emergency point and which specific human person within the public emergency point is handling the call.
The existing private emergency points have the problem that they do not have access to these routing tables and cannot easily know the next local public emergency point. They need costly methods to keep the private emergency point lists up-to-date somehow. Even if they managed this problem, they would still have not insight into the public emergency point internal diversion or forwarding.